home *** CD-ROM | disk | FTP | other *** search
/ Columbia Kermit / kermit.zip / newsgroups / misc.19960715-19961006 / 000083_news@columbia.edu _Sat Jul 27 11:06:58 1996.msg < prev    next >
Internet Message Format  |  2020-01-01  |  8KB
  1. Return-Path: news@columbia.edu
  2. Received: from newsmaster.cc.columbia.edu (newsmaster.cc.columbia.edu [128.59.35.30]) by watsun.cc.columbia.edu (8.7.5/8.7.3) with ESMTP id LAA17124 for <kermit.misc@watsun.cc.columbia.edu>; Sat, 27 Jul 1996 11:06:57 -0400 (EDT)
  3. Received: (from news@localhost) by newsmaster.cc.columbia.edu (8.7.5/8.7.3) id LAA16695 for kermit.misc@watsun; Sat, 27 Jul 1996 11:06:56 -0400 (EDT)
  4. Path: news.columbia.edu!watsun.cc.columbia.edu!fdc
  5. From: fdc@watsun.cc.columbia.edu (Frank da Cruz)
  6. Newsgroups: comp.protocols.kermit.misc,comp.dcom.modems
  7. Subject: Re: Problem getting 28800 bps in C-Kermit 5A(190) on a v.34 internal
  8. Date: 27 Jul 1996 15:06:32 GMT
  9. Organization: Columbia University
  10. Lines: 151
  11. Message-ID: <4tdb9o$p4o@apakabar.cc.columbia.edu>
  12. References: <CROTEN.96Jul24005129@crl.crl.com> <4t63nh$imc@samba.rahul.net> <CROTEN.96Jul27005455@crl.crl.com>
  13. NNTP-Posting-Host: watsun.cc.columbia.edu
  14. Xref: news.columbia.edu comp.protocols.kermit.misc:5656 comp.dcom.modems:145799
  15.  
  16. In article <CROTEN.96Jul27005455@crl.crl.com>,
  17. Charles Roten <croten@crl.crl.com> wrote:
  18. : Sorry, Clarence .. I added ',comp.dcom.modems' to the '^Followup-To: ' and 
  19. : '^Newsgroups: ' lines again, due to the presence of some modem-chipset 
  20. : related issues.  Since _both_ you _and_ Frank Da Cruz warned me about the 
  21. : "Rockwell RPI" chipset problems, I decided to take you _both_ seriously 
  22. : about this issue.  Though I still am not sure whether my modem has this 
  23. : problem or not .. and indeed had never heard of it until your responses to 
  24. : my earlier post.  
  25. : 
  26. See item 20 of the Kermit FAQ:
  27.  
  28.   http://www.columbia.edu/kermit/faq.html
  29.   ftp://kermit.columbia.edu/kermit/faq.txt
  30.  
  31. : BTW, are there any diagnostics for this problem, other than the one Clarence 
  32. : Dold alludes to below ??
  33. :
  34. In general, the modem-specific command to enable error correction or data
  35. compression results in an ERROR response.  Also I think the product ID shown
  36. by ATI3 should say RPI in it somewhere.  But none of this is universal; every
  37. modem is different.
  38.  
  39. : BTW, Frank Da Cruz _seems_ to imply _none_ of these mods are neccessary in 
  40. : order to enable "fullscreen" display on a SunOS 4 box.  Maybe I went off 
  41. : on an unneccessary tangent here ??  
  42. : 
  43. Correct.
  44.  
  45. : But there _does_ seem to be a problem here, perhaps with interaction with 
  46. : the antique windowing system (Sunview) my box uses.  _Any_ interaction 
  47. : between any ovelapping window _or_ Sunview itself (such as closing the 
  48. : window in which I use C-Kermit) and the "vttool" vt100 emulation window I am 
  49. : (now) using as a C-Kermit terminal emulation front end can "freeze" Suntools 
  50. : _totally_ for minutes to hours.  The only way of breaking out _by_ _choice_ 
  51. : seems to be a system reboot.  Ugly.  
  52. : 
  53. Not a Kermit problem.  The fullscreen file transfer display works fine on
  54. hundreds of different UNIX platforms.  It uses standard curses library calls.
  55. On some platforms there are bugs in the curses library (typical symptom: it
  56. works the first time, does not work subsequent times).  In other situations
  57. there can be bugs in the terminal emulator or windowing system through which
  58. you view it.  Or (but probably not in your case) a simple mismatch between the
  59. type of terminal curses thinks you have (look at your UNIX TERM variable) and
  60. the type you actually do have.
  61.  
  62. : Hmm .. no problem seen so far with 19200 .. except an apparent inability to 
  63. : get above that throughput except fleetingly and temporarily during downloads 
  64. : where _overall_ efficiency is rated by "stat" right at 50% (or a hair under) 
  65. : for a _38400_ _bps_ connection.  I would expect 60-66% if I were receiving 
  66. : at 28800 bps, of course.  
  67. : 
  68. How do you know the connection is really at 28800 bps?  Did the modem say so
  69. in its CONNECT message?  How do you know the connection *stayed* at 28800 bps?
  70. V.34 modems can shift down (and hopefully) back up at any time during the
  71. connection, perhaps repeatedly.
  72.  
  73. : >Do you get a "CONNECT xxx00, LAP-M" or something like that?
  74. : 
  75. : Nope .. just "CONNECT 38400".  No ", LAP-M" suffix at all.  
  76. : 
  77. Sounds like you don't have an error-corrected connection.  That could be
  78. because your modem doesn't *do* error correction, or because it does, but the
  79. other one doesn't, or because they both do, but nevertheless failed to
  80. negotiate a common error correction protocol.  Or it could simply be that you
  81. have configured the modem not to issue protocol messages in its result codes.
  82. Look in your modem manual at the X command (X1, X4, etc)...
  83.  
  84. : set line /dev/ttym1
  85. : set incomplete keep
  86. : set flow rts/cts
  87. : set speed 38400
  88. : set dial speed-matching off
  89. : set parity none
  90. : set send packet-length 9000       <-- Not needed, see manual
  91. : set receive packet-length 9000    <-- This might be overkill
  92. : set window 1                      <-- See below
  93. : ...
  94. : 
  95. : Another problem I get from this combination of C-Kermit, terminal emulator, 
  96. : and windowing system on my box is the (quite sudden) interruption of a file 
  97. : transmission with the "too many NAKs" complaint from C-Kermit.  
  98. : 
  99. Try using a shorter packet length and a bigger window size.  For example:
  100.  
  101.   set window 4
  102.   set receive packet-length 1000
  103.  
  104. Given the uncertainties about your modem, you certainly don't want to stress
  105. it with 9000-byte packets until after you have achieved satisfactory results
  106. with more conservative settings.  The rule is:
  107.  
  108.  1. Get it working reliably
  109.  2. Then vary the packet and window sizes until optimum throughput is achieved
  110.  3. Then (maybe) add some control-character unprefixing
  111.  
  112. See the Kermit FAQ for a longer explanation.
  113.  
  114. : Could this be an artifact of the fact that these file transmissions are 
  115. : from a host in California (crl.com) which mounts C-kermit, _through_ _a_ 
  116. : _telnet_ _connection_ _from_ _an_ _intermediate_ _host_ (a local Seattle-
  117. : based ISP .. crl.com has no Seattle POP), to my local UNIX box ?  
  118. : Yeah, I know .. a wierd way to do things ..  
  119. : 
  120. Yes, of course that will slow things down.  And although you did not say
  121. anything above about control-character unprefixing, I should warn you that if
  122. you start unprefixing control characters to get more performance (which you
  123. can read about in our FAQ and in the online C-Kermit documentation), take
  124. care not to unprefix Telnet's escape character, or the character 255, or
  125. carriage return.  (Of course, none of these are unprefixed by default.)
  126.  
  127. : Owing to the fact that I am not _sure_ of binary file transmission accuracy
  128. : in this "relayed" mode, I uuencode any file which even I _suspect_ of
  129. : containing non-printable characters.  Then, when the "too many NAKs" bug
  130. : shuts me down, I can use UNIX "split", fore and aft, on the (uuencoded)
  131. : file, throwing away the last line or two on the receiving box and the lines
  132. : before that on the one sending.
  133. :
  134. You don't need to do any of this.  Kermit itself acts like a "uuencode"
  135. program to ensure that binary data gets through even the toughest kinds of
  136. links.  Just use the defaults.  If the transfer through your intermediate
  137. Telnet program doesn't work, that means you don't have an 8-bit Telnet
  138. connection, in which case simply tell the sending Kermit to:
  139.  
  140.   set parity space
  141.  
  142. and then it will work.
  143.  
  144. Should the transfer fail partway through, use the built-in recovery feature
  145. (the RESEND command).  Read about it in the online documentation that comes
  146. with C-Kermit.
  147.  
  148. : I'll try out the effect of 'set dial speed-matching off' in my .kermrc later
  149. : this evening.  Thanks.  I just hope it helps throughput, but I don't hold
  150. : out much hope of it assisting the fragility of Sunview in the presence of an
  151. : ongoing C-Kermit download in a vttool window.
  152. : 
  153. Sunview and vttool are problematic only in their response to the curses
  154. display.  To avoid problems, just use some other form of display:
  155.  
  156.   set file display crt
  157.   set file display serial
  158.   set file display none
  159.  
  160. Curses itself on SunOS is fine.  If you use some other terminal or emulator
  161. with SunOS C-Kermit there are no problems at all with the display.
  162.  
  163. Again, please consult the manual "Using C-Kermit", plus the accompanying
  164. online documentation, and our FAQ to save yourself lots of trouble.
  165.  
  166. - Frank